Before applying, verify this suggestion against the current code. In
modules/comet_eks/main.tf, add Terraform state migration blocks for the resources
removed from config so upgrades don’t plan destructive changes. Around lines 733-819,
create `moved {}` (preferred) or `removed {}` blocks for kubernetes_storage_class.gp3
and kubernetes_storage_class.comet_generic, matching the correct old resource addresses
exactly as they existed in state. Around lines 1067-1183, do the same for
kubernetes_namespace.monitoring and kubernetes_secret.monitoring. Around lines
1522-1683, do the same for kubernetes_namespace.redis_insights. Follow the same
moved-block style/location already used for EKS addons in this file (lines ~612-635),
and map `to` addresses to where these objects are now managed in-repo
(comet-infra/comet-devops) or use `removed` if they’re now fully external.

Before applying, verify this suggestion against the current code. In
modules/comet_eks/main.tf around lines 1522-1525 (the “Redis Insights namespace”
section), the code now only contains a comment claiming the redis-insights namespace was
moved and is no longer created here. Fix this by checking the replacement
agentro-role/rbac local module in the comet-devops code (search for redis-insights
namespace/RBAC/port-forward bindings); if it does not create `namespace redis-insights`
(and any required Role/RoleBinding/etc.), add those resources there so the namespace
exists before any workflows rely on it. Also verify how `enable_redis_insights_ns` was
previously used and either (a) re-wire that enablement into the agentro-role/rbac
module, or (b) deliberately make creation unconditional and remove/adjust the old
variable without changing behavior unexpectedly. Finally, ensure there is Terraform
dependency ordering between the provisioning of redis-insights objects and whatever
module/workflow uses them (e.g., via explicit depends_on or module output dependencies).

Before applying, verify this suggestion against the current code. In variables.tf around
lines 901-903, update the “StorageClasses moved to the comet-infra umbrella chart
(ArgoCD) in v5.0.0” comment (the hunk that replaced `eks_storage_class_reclaim_policy`
/ `eks_create_comet_generic_storage_class`) to include an explicit migration mapping for
downstream users. The current note only says the inputs were removed and replaced by
chart values, but it does not name the exact comet-infra umbrella chart value keys that
control (1) StorageClass reclaimPolicy for gp3 and comet-generic and (2) whether
comet-generic StorageClass creation is enabled to avoid Helm/ArgoCD dual ownership.
Refactor by adding the concrete replacement value names and how to set them (including
which behavior is unchanged, e.g., gp3 always created), pulling the exact keys from the
comet-infra umbrella chart’s values.yaml/docs so v5 users can migrate without failing
contract validation.

Before applying, verify this suggestion against the current code. In variables.tf around
lines 1628-1632 under the “Namespace nodegroup pinning + Redis Insights — REMOVED in
v5.0.0” comment block, update the migration note to include a clear replacement
contract for users who previously set enable_namespace_nodegroup_pinning, app_namespace,
admin_pinned_namespaces, and enable_redis_insights_ns. Explicitly document that these
Terraform variables are removed and that consumers must configure the equivalent
behavior via the GitOps/ArgoCD/agentro-role/rbac inputs/values; then search the repo for
where redis-insights namespace creation and any nodegroup pinning behavior are now
controlled (e.g., the agentro-role/rbac module/values files) and reference the exact
values/paths/names in the comment. Also add a short “migration steps” checklist
(what to delete from tfvars, what to set in GitOps) so that users don’t keep passing
removed args and hit v5 input validation failures.